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EXECUTIVE  SUMMARY 


1.  INTRODUCTION 


Orlando  II  is  the  fourth  in  a  series  of  biennial  workshops  focusing  on  relevant 

software  support  issues  pertinent  to  Mission  Critical  Computer  Resources 

(MCCR).  The  previous  workshops,  Monterey  I  &  II  and  Orlando  I,  were 
instrumental  in  the  identification  of  issues  that  could  be  addressed  in 
Department  of  Defense  (DOD)  standards  for  the  development  of  mission  critical 
systems.  One  of  those  issues  dealt  with  how  to  handle  the  problems  associated 
with  Post  Deployment  Software  Support  (PDSS)*  The  central  theme  of  Orlando 
II  was  "Solving  the  PDSS  Challenge".  The  Orlando  II  Workshop  addressed  the 
problems  causing  the  current  crisis  in  support  of  MCCR.  The  workshop 

selectees  were  assigned  to  one  of  eight  panels.  Each  panel  was  assigned  one 
particular  PDSS  related  topic  and  tasked  to  identify  PDSS  problems  concerning 
that  topic.  The  panel  then  was  to  develop  solutions  which  offer  significant 

payoffs  in  terms,  of  cost  reduction,  improved  system  reliability,  and  streamlining 
the  PDSS  process. 


Specific  panel  topics  were  as  follows: 

E  PDSS  Planning  During  Development 

II.  Forecasting  PDSS  Resource  Requirements 

III.  Software  Change  Process 


IV.  PDSS  Standards 

V.  PDSS  Management  Indicators  and  Quality  Metrics 


VI.  Human  Resources  in  PDSS 
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VIII. 


Software  Technology  Transition, 
MCCR  Security . 
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is  document  is  the  Executive  Summary  which  presents  a  synopsis  of  each 
panel’s  topics,  concerns,  and  recommendations.  The  panels  were  assigned  areas 
that  would  allow  sufficient  latitude  in  reviewing  PDSS  concerns  and  proposing 
recommendations  for  DOD  and  industry  implementation.  Detailed  information  on 
the  workshop  is  contained  in  separate  volumes*  Volume  I  is  a  summary  of 
products  and  recommendations,  Volume  II  is  the  complete  workshop 
proceedings,  and  Volume  III  is  the  action  plan  that  contains  tne  specific  tasks 
developed  by  the  eight  panels. 

The  following  paragraphs  present  a  synopsis  of  the  related  panels  deliberations. 
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2.  INDIVIDUAL  PANEL  SYNOPSIS 


2.1  Panel  I  -  PDSS  Planning  During  Development.  This  panel  examined  how  to 
improve  PDSS  effectiveness  and  timely  use.  They  reviewed  the  various 
planning,  policy  and  budget  issues  that  affect  PDSS.  A  major  recommendation 
was  that  PDSS  must  be  recognized  as  covering  an  entire  program’s  life  cycle. 
PDSS  considerations  must  therefore  be  addressed  in  the  Request  for  Proposals 
(RFPs),  contract  awards,  and  milestone  reviews.  An  equally  important  issue 
concerned  the  problems  surrounding  the  data  rights  for  software,  and  how  to 
improve  the  Government’s  ability  to  obtain  those  rights. 


2.2  Panel  II  -  Forecasting  PDSS  Resource  Requirements.  This  panel  explored 
how  to  achieve  successful  planning  for  software  resources  through  the 
utilization  of  proper  tools  to  help  in  the  decision  process.  A  key 
recommendation  was  that  each  Service  should  adopt  a  policy  to  implement  a 
Constructive  Cost  Model  (COCOMO)-like  forecasting  method.  To  improve 
forecast  accuracy,  standardized  software  data  collection  should  be  initiated  to 
calibrate  model  computational  algorithms.  Also,  models  should  be  refined  and 
enhanced  through  additional  research.  To  ensure  Service  representatives  and 
associated  contractors  are  adept  at  using  various  methods,  a  training  program 
should  be  initiated  to  cover  software  cost  estimating  methodologies.  Tne  long 
term  goal  would  be  the  adoption  of  a  standard  DOD  Software  Cost  Estimating 
(SCE)  model. 


2.3  Panel  III  -  Software  Change  Process.  This  panel  examined  the  PDSS  model 
developed  in  the  Orlando  I  Workshop  to  determine  if  it  was  too  complex  and 
how  to  simplify  it.  As  a  basis,  they  recommended  that  the  original  PDSS 
definition  (not  the  model)  be  accepted  as  an  initial  baseline.  The  definition  is: 

"Post  Deployment  Software  Support  is  the  sum  of  all 
activities  required  to  ensure  that,  during  the  production/ 
deployment  phase  of  a  mission-critical  computer  system’s 
life,  the  implemented  and  Fielded  software /system  continues 
to  support  its  original  operational  mission  and  subsequent 
mission  modifications  and  product  improvement  efforts." 

In  addition,  PDSS  should  be  broken  out  into  three  standard  areas:  management, 
technical,  and  support.  The  panel  also  recommended  that  the  Computer 
Resources  Life  Cycle  Management  Plan  (CRLCMP)  be  revised  to  reflect  a  PDSS 
strategy  decision  early  in  the  CRLCMP  development,  thus  allowing  future 

planning  to  have  a  basis  from  which  to  build  and  request  resources  from. 

Surrounding  the  basic  PDSS  modeling  is  the  process  of  the  configuration 

management  (CM)  which,  if  implemented  properly,  has  a  positive  effect  on  the 
system  in  terms  of  PDSS.  The  panel  discovered  there,  were  inconsistencies  and 
deficiencies  in  current  DOD  CM  directives  and  standards.  They  recommended 
updating  current  policies  and  developing  a  common,  automated,  software 

Configuration  Status  Accounting  (CSA)  system.  All  of  this  would  be  followed 
by  appropriate  handbooks  to  assist  DOD  activities. 
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2.4  Panel  IV  -  PDSS  Standards.  Panel  IV  reviewed  the  Defense  System 
Software  Development  Standard  (DOD-STD-2167)  and  the  draft  of  the  Defense 
System  Software  Quality  Program  Standard  (DOD-STD-2168)  for  applicability  to 
PDSS.  They  found  that  there  were  areas  that  would  require  improvement  if 
PDSS  is  to  be  addressed.  The  consensus  was  that  the  development  standard  was 
the  ideal  avenue  to  start  the  PDSS  process,  the  earlier  the  better.  The  panel 
noted  specifics  from  an  Army  standard  that  would  enhance  DOD-STD-2167. 
Specific  comments  on  DOD-STD-2167  were  generated  by  the  panel  and 
forwarded  to  the  Joint  Policy  Coordinating  Group  for  Computer  Resource 
Management  (JPCG-CRM). 


2.5  Panel  V  PDSS  Management  Indicators  and  Quality  Metrics.  The  panel 
addressed  the  need  to  have  management  indicators  and  quality  metrics  on 
contracts  in  order  to  establish  the  software  development  discipline  as  a  science 
and  to  assure  continuation  of  a  quality  product  during  the  PDSS  process.  The 
under-utilization  of  available  indicators  precludes  weapon  system  warranties  and 
decreases  the  Government’s  ability  to  measure  the  performance,  cost,  and 

schedule  constraints  that  the  software  must  operate  under.  With  the  lack  of 
metrics  use,  the  ability  to  share  data  across  DOD  and  industry  is  impaired. 
Panel  V  recommended  automating  the  metric  gathering  process,  incorporating 

metrics  into  current  DOD  policies,  and  allowing  the  transition  of  metric  data 

from  the  development  agencies  to  the  maintamers  to  avoid  redundancy  and 

excessive  maintenance  costs. 


2.6  Panel  VI  -  Human  Resources  in  PDSS.  The  panel  addressed  how  to  recruit, 
train  and  retain  knowledgeable  software  personnel  to  support  PDSS.  Their 
review  concentrated  on  educational  and  training  initiatives,  plus  various  career 
management  procedures.  The  major  thrust  that  developed  was  the  need  for  a 
consolidated  approach  to  software  engineering  training,  with  an  increased 
awareness  by  DOD  management  that  this  type  of  training  is  necessary.  The 
panel  recommended  that  an  Ad  Hoc  group  be  formed  to  address  these  concerns 
and  make  specific  recommendations  to  DOD  management,  and  that  a  new 
software  engineering  job  series  for  the  Government  and  civilian  workforce  be 
established. 


2.7  Panel  VII  -  Software  Technology  Transition.  The  panel  concentrated  on 
identifying  policies  and  methods  to  transition  the  necessary  software  tools 
from  the  development  phase  to  the  support  phase  of  the  systems  life  cycle, 
while  at  the  same  time,  controlling  their  proliferation.  This  area  involved 
addressing  the  productivity  of  Ada  tools.  A  key  point  was  that  there  was  a 
need  to  identify,  procure,  and  provide  widespread  distribution  of  common  PDSS 
tools,  methods,  and  processes.  Three  major  recommendations  were  put  forward: 

1)  Develop  a  PDSS  training  program  for  Program  Managers. 

2)  Establish  a  joint-Service  PDSS  software  commonality  office  to 
help  in  the  tools  transition. 

3)  Establish  cost  effective  criteria  for  Ada  conversion. 
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2.8  Panel  VTTI  -  MCCR  Security.  The  specific  tasks  this  panel  reviewed 
concerned  the  lack  of  computer  security  in  delivered  systems.  This  compounds 
the  difficulty  in  dealing  with  the  PDSS  process,  since  there  currently  is  little 
guidance  for  specifying  and  assessing  MCCR  security  requirements.  Existing 
computer  security  guidelines  do  not  adequately  address  MCCR  requirements. 
The  major  recommendations  of  the  panel  were  to  provide  more  direction  in 
DOD-STD-2167,  which  provides  initial  guidance  for  MCCR  security.  However, 
additional  tasking  is  required  which  involves  development  of  automated  tools 
and  techniques  to  support  trusted  systems  and  the  development  of  an  efficient 
and  effective  MCCR  security  architecture. 


3.  SUMMARY 

The  Orlando  II  Workshop  addressed  a  wide  variety  of  issues  concerning  Post 
Deployment  Software  Support.  The  challenge  was  to  identify  key  issues  and 
drivers;  this  was  accomplished.  In  addition  to  the  identification  of  key  PDSS 

areas,  each  panel  proposed  solutions  that  could  ensure  PDSS  would  be  a 

discipline  to  be  evaluated  and  designed  into  our  weapon  systems  in  the  future. 

The  task  now  before  the  JLC  is  to  push  forward  into  the  FDSS  area  and 

establish  it  as  a  viable  systems  engineering  parameter  that  affects  a  weapon 
system  more  than  any  state-of-the-art  technology  would. 


Any  questions  concerning  this  material  may  be  forwarded  to: 

Chairperson,  PDSS  Subgroup 
Ms.  Shirley  Peele 

Fleet  Combat  Direction  Systems  Support  Activity 
Dam  Neck,  Code  82 
Virginia  Beach,  VA  23461 

Telephone:  AUTOVON  433-7257  or  (804)  433-7257. 
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